5.1. Usefulness vs. Cost of implementation of some properties
5.1.1.
Further discussions on public forums are needed about the usefulness of the following properties and if there could be simpler ways to solve the use cases they were made for:
5.1.1.1.
EXRULE — This recurrence property is cumbersome to use and the equivalent can be generated with a list of EXDATEs. This property could be removed for better interoperability.
5.1.1.2.
BYSECOND — This recurrence rule part is not useful in a human-interaction system and since that is our target, not automated systems, this rule part should be removed for better interoperability.
5.1.1.2.1.
How to handle seconds if they are received? If a client receives an RRULE with a DTSTART that has non-zero seconds, the client can ignore the seconds without having to round up, which might have pushed the time into the next hour or day.
5.1.1.3.
BYSETPOS — This RRULE property is useful in that it has the “payday” use case, ie. last workday of the month, but can be complicated to implement. The sender could use RDATEs as well but could be a lengthy list if this goes on yearly, etc. It is better to send a list of RDATEs with exceptions already taken into account, and refresh this at appropriate intervals to extend the set. If that is recommended in the RFC, then this property could be removed. Recommend going to the CALSIFY list to see if this is deemed a workable solution.
5.1.1.4.
Multiple EXRULEs and RRULEs — These properties combined are complicated to implement, are not supported by many implementers, so support for multiple EXRULEs and RRULEs should be removed from the iCalendar RFC and related memos.